Nice. 🥳
Can you add a screenshot when ready?

Generated by 🚫 Danger

default (ISO 8601):

"ar-AF" locale:

"dv-MV" locale:

Even though I spent quite a bit of time trying to make our custom configuration work alongside cal-heatmap, this approach makes a bit more sense. Modifying the library ended up requiring more code than writing the config itself.

I really like that this removes the third-party dependency and results in a much cleaner, more maintainable, and self-contained solution.

Just a quick question: what border-radius did you end up using for the squares? It seems to vary slightly across the three screenshots. Also, slightly increasing the spacing between columns and rows could help make the heatmap look a bit more balanced and visually appealing.

Thank you.

It's always 1px from bootstrap, although I certainly don't like to send 3.5 kb of rounded-1 I've tried to use bootstrap for most of the styling.
The seeming variation comes from the grid scaling to the available width (see how the heading apparently scales as well), so the grid gap should maybe be given as a percentage?

With this approach is the javascript actually doing anything that couldn't be done in the rails rendering on the server?

I've stopped just short of the layout because it depends on the CLDR's supplemental weekData which I can use with Intl.locale.

The TwitterCldr gem doesn't have the supplemental data necessary for doing the layout in Ruby.

Nothing is stopping us from reading https://github.com/unicode-org/cldr-json/blob/main/cldr-json/cldr-core/supplemental/weekData.json ourselves, but that needs territories as the input, not just the locale, and idk if that information is available to the server (request with en might mean US or GB which have different weekData).

I've now moved the bootstrap styling to the CSS, saving about a dozen+ kB in the page response size.
Also data-month now counts beyond 12 so I don't have to deal with jQuery selecting both labels of the same month.
And I've fixed the month labels when the calendar reaches into a month by adding more padding for the month label generation.

I've noticed that the border radius of the day cells changes between desktop and mobile — it looks slightly rounded on desktop but becomes almost pill-shaped on mobile. If this isn’t intentional, we might want to set a fixed border-radius to ensure visual consistency across breakpoints.

Desktop:

Mobile:

On macOS using firefox, when scrolling horizontally, the scrollbar overlaps with the heatmap area. It might be a good idea to add some padding at the bottom of the container to prevent this overlap and improve the scrolling experience.

It might also be a good idea to apply light/dark variants for tooltips based on the current theme to keep visual consistency.

we might want to set a fixed border-radius

This is what is currently being applied with Bootstrap's rounded-1, but I agree a relative border-radius looks more consistent.

the scrollbar overlaps with the heatmap area

I've added mb-1 as a compromise between thick overlaid and classic scrollbars, as I can't get scrollbar-gutter to produce the desired effect.

apply light/dark variants for tooltips

That's what Bootstrap already does, although to prevent the tooltip "merging" with the background and for better accessibility, dark tooltips are used in light mode and light ones in dark mode.

I don't like the green. Also, it should show the current day, right now on May 16th I only see up to May 15.

Could this be a new edition of #5802 but for days? And caching is probably also involved.

Which green would you prefer (and for which color scheme)?

In general it would be better to open a new issue for that though.

Which green

The same one as github

and I think their implementation of just 5 color buckets is easier to read than a continuous gradient.

Also, it would be cool if there was a "See more" button that would load the entire contribution graph since account creation, like github lets you click through the years

The yearly history has already been mentioned in #5829, which should IMO be a precondition for that.

And anything involving different light and dark color palletes requires watching the color scheme media query again, which I really want to avoid.

I'm not 100% sure merging of this PR is causing this, but take a look at how e.g. my profile page looks now (Edge, Chrome, .. every browser and user profile I tried):

nenad-vujicic > ... looks now (Edge, Chrome ...

I can partly agree.

Looks OK to me in both Firefox and Chromium on linux whether or not I am logged in.

I think I've found the culprit:

See #6018

just 5 color buckets is easier to read than a continuous gradient

for example I can't see any of my contributions because in the last few months I've had days with a lot more contributions